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[Text] ©. SUMMARY 


The Commission of the European Communities has produced a set of guidelines for 
the way informatic seivices should be used within its own sdministration. and 
for the way informatics resources should be deployed. It is expected that they 
will lay the foundations of <a well-coerdinated plan for procurement and 
implementation of informatics across European Institutions. 


The plan, as expressed by these guidelines, has. as its basic aim, to allow the 
Evropean Institutions to 


Be free to choose the best way of adopting end integrating new *echnology 
independently of the policy of individual manufacturers 


The stated objectives to achieve this aim are 
. To modernise the administration of the European Institutions and organise 
the flow of information between them and the Member States Administrations 


by the INSIS programme (Interinstitutional System for Integrated Services! 


* To implement «s multi-vendor orocurement policy. showing that it is 
economically justified in a standarcised environment 


° To promote cooperation between manufacturers in promulgating standards and 
adhering to them 


® To strengthen interinstitutional cooperation in informatics sllowing the 
sharing of benefits resulting from the combiration of the purchasing power 
of seperate Institutions. 


, To set an example to public and private bodies in Europe in procurement 
policy for informatics products. 


There are two main. closely related, fronts through which the guidelines 
propose to implement these sims 


- A coherent policy in implementing standards 


A rational deployment of informatics resources, reflecting more closely the 
way user communities are organised. 











Standards are essential for intercormunication between institution< and 
eventually interworking. They are also essential for interconne: tion, 
intercommunitcation and interworking within a single institution. Last. bit not 
least. they are essentiel for the independe ce from individual manufacturers. 
the protection of investment® against obsolescence and for the free competition 
within the informatics industry 


The guidelines adopt fully. and on a mandatory basis, the implementation of the 
Principle of Open Systems Interconnection (OSI) for all matters that involve 
communication between different equipment and institutions. They go further 
than the OSI principle. however, Dy proposing practical ways of cooperating in 
the impiementation of application systems with view to interworking on an 
user-to-user basis. as opposed to simply machine-to-sachine 


The proposed measures include the urgent adoption of a standards intercept 
strategy. im concert with the manufacturers who will implement them on their 
products, as well as the adoption of a limited range of software products to 
avoid the proliferation of incompatible systems. A good example of the latter 
1s a decicion not to introduce new proprietory operating systems. and the 
chuice of transportable ones, such as UNIX and MS-DOS. These enhance the common 
development and interchange of applications, and make possible the introduction 
of an unified user environment 


The deployment of informatics resources proposed in the guidelines is based on 
a distributed architecture which reflects closely the way user communities are 
Organised. The open systems principles resulting from the adoption of suitable 
standards provide the flemidi ity needed to imp lement the proposed 
architecture 


Essentially, this is @ two level architecture which distinguishes. within an 
Institution, between Local Support Units ({(LSUs!) dedicated to 4 local wser 
community with a close working relationship and Common Support nits (CSU) 
dedicated to the organization as a whole 


LSUs are intended to cover flexibly the different user requirements of 
Gifferent user communities. CSUs are used for services *hat cannot be provided 
economically within a@ smell user community. cannot be practically distributed 
fe g. common data bases). or are centralised Dy definition. surh as common 
accounting. communicalion between organizations, etc 


The guidelines recognise the fact that the capabilities offered by information 
technology finally reach the users in the form of different services such as 
electronic mail, persons! computing. access to data DBDases. etc for this 
reason. @ substantial part of the guidelines is dedicated to these services and 
is of @ dynamic nature. The guidelines for the implementation of services #11) 
be constantly under review and new guidance will be added as experience is 
gained and as new requirements materialise 


The guidelines slso recognise the fact that the trans! ion from a manufacturer 
Orierted architecture to an open one allowing full interworking cannot he 
achieved overnight. The guidelines foresee an evolutionary plan which will 
Gradually attain the intended goal. This plan contains valuable information for 
the industry on the difficuities «a customer meets when implementing « 
multi-vendor standards policy. 
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It is believed that the plan inherent in the guidelines is both 
timely. Although information technology is not new and expands at an 
a wide scale is still in its formative stages 
of all manufacturers of the expanding technology 
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t INTRODUCTION 


The unprecedented growth in information and communication technology of the 
past years presents both challenge snd opportunity to user orgenisations 


The opportunity is that techedclogy can be applied to enhence the 
effectiveness ane efficiency of organisetions to a higher degree than was 
possible before 


The challenge is caused by the proliferation of products which makes 
standardisation a pre-requisite for integretion. 


It as in the interest of all, and especially of large organisations, to 


Remain free to choose the best way toe adopt and integrate new technology 
independently of the policy of individual manufacturers 


In addition, the European Institutions must cope with the complexity caused by 
different languages and partners in remote geographical locations. This turns 
the interest into «a necessity, and dictates conditions for s high degree of 
flexibility in implementing these technologies 


The degree of interaction between the European Institutions makes essential the 
adoption of a master plan for implementing the growing technologies This 
should encompats communications end areas of common interest between European 
Institutions and the Administrations of the Member States of the European 
Community 


The proposed master oplen (the Informatics Architecture of the European 
Institutions!) has a6 its main elements 


* A distributed data processing architecture 
* A aulti-vendor procurement policy 

* Common standards for system interworking 

* Maxieue traensportebility of software 


This architecture ought to reflect more than the solution to the needs of the 
Evwropeen Institutions. The European Institutions have to play @ leading role to 
encourege harmonisation in informstics, which showld be to the Benefit of 
Evropes) industry at lerge 








The following objectives are, therefore, adopted to achieve the goals set out 
earlier 


a To modernise the administration of the European Institutions and organise 
the information flow between them and the Member State Administrations Dy 
the INSIS programme (Interinstitutional System for Integrated Services). 
and CADDIA {Cooperation in Automation of Date and Documentation for 
Import/Export and Agriculture). 


b To demonstrate that a multi-vendor procurement policy is economically 
Justivied in a standardised environment because it reduces the cost of 
dependence on a single supplier while avoiding the cost of hardware 
redundancy. 


c To obtain an undertaking from manufacturers to cooperate in promulgating 
standards and to comply with them in the products they offer to all their 
customers 


6 To strengthen interinstitutional cooperation in informati-s. This will 
allow the sharing of benefits between Community Instituticns who have their 
Own purchasing power. 


° To set an example to pwblic and privete bodies in Evrope in procurement 
policy for informatics products. 


The tasks set out are not easy Most architectures have been designed by the 
computer manufacturers to fit with their present end future product ranges 

Such architectures are, generally. mutwally incompatible even if OSI standards 
are applied A multi-wendor architecture can only be developed by the customer. 
but mo single customer has the power to impose s given architectursl design on 
industry A multi-vendor architecture must. consequently. result from the 
iterative process of demand and supply. 


This is the spirit in which these architectural guidelines have been prepared 

They reflect neither too specific customer needs, nor particular design 
concepts : moreover, they take into account the availability of products on the 
market. This is an additional reason why the guidelines themselves are under 
constant review and correction, end why some important subjects are not 
included when the standardisation process does not point to genersl and common 
sense solutions. In the next edition of the guidelines # more advanced analysis 
of some of these subjects will be covered. such as: 


® Introduction of ISON and finel selection of LAN standards 
® Network managemcnt and addressing scheme 

. Encryption ; 

° Integration of servers 


° User interface standardisation ; 


® Document management 








The Commission of the European Communities would be grateful to receive 
information and suggertions for the next edition of these guidelines at the 
following address. where also extra copies of this document can be ordered 


COMMISSION OF THE EUROPEAN COMMUNITIES 
Directorate of Informatics 

Jean Monnet Building - Room C2-84 
L-2920 LUXEMBOURG 








2 ARCHITECTURE 


2.1 Structuring 


The aim of the architecture is to fulfil the objectives stated in the 
introduction and allow the integration of data, text. graphics, image. voice 
etc.: it is an oper architecture 


To the end user, the architecture appears at services delivered via a single 
workstsetion. Some important services, to which attention will need to be paid 
in the 1986-199! period. are : user agent services, information produ: tion and 
administration information Gissemination service, electronic mail, and 
application service 


User populetior of autonomous organisatica®?. such as private companies 
government atministrations and European institutions have independent 
informatics management <«tructures Following the CCITT (1) terminology, they 
will be catiled Peavate Domains Private domains will communicate wis Public 
Communication Networks (PCN) and wte services delivered by Public DPomains, 
which are managed by public telecommunication administrations (PTTs) 
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(1) CCITT « International Telegraph and Telephone Consultative Committee 








The distinction between public and «6ptivate domains implies a distinction 
between an inter- and intra-domain architecture. The first has to be determined 
by common agreement between all domains concerned The management of eacn 
Gomain is autonomous in Getermining its intra-domain architecture The 
Gefinrition of the intra-domain architecture however, is Significant if 
end-user interworking across domains is to be achieved 


The intra-domain architecture of the CEC is based on distributed processing 
Services are provided by means of hardware, software, networks, and support 
(the infrastructure) 


The user accesses the architecturé’through 2 workstation. A workstation may be 
» telephone set. visual display, keyboard, printer, document entry station, 
etc. Ideally, the user snould need just a single multi-function workstation to 
access all awailable services. How services are obtained beyond the workstation 
should be transparent 


The workstation communicates with hosts distributed in the nretwork. A host is 3 

mputer with it- operating system and its communication interfaces It 
provides the host environment fora set of servers. A server is a software 
package and the resources, it draws from its host. In order to deliver a service 
t the user, ‘such as access to data bases, electronic mail, information 
production, document management and application services). it is necessary to 
set up a flow of communication between cooperating servers which together 
produce the service {*) 


Host 1 Host 3 
a 7 = 
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{*) The term “service” in this document means “service to the user’, and does 
not refer to the service that exists between the layers of the OSI model 





= 
In order tw cope with all possible combinations of hosts and serwers, which may 
occer in the course of time. it must be technically possible for any server ¢ 
Communicate with any other server. This implies the principle of Open System 
Interconnection (OSI) and the implementation of the related standa ts (see § 


3.2) 


However. OSI is only 2 means to the end of corstructing a good architecture 
The architecture itself is the structure of the solution to the needs of the 
wsers and must define 


- how services are set up by cooperating servers 
- how servers are mapeed onto »osts 
- how hosts ere distributed into the networ® 


To answer these questions, the distinction between “host” and “server” made 
abowe is of materisl importance. 


The architecture consists of rules for structuring ; mot rigid pre-defined 
structures. The rules themselves will change in the course of both technical 
evolution, and eventual changes in the users pattern of behaviour. The rules 
are dictated by the technical, functional. and economical relationshigs between 
technology on the one hand. and user activity on the other The resulting 
arcoitecture must. at any one time 


- Fit the organisational structure of user populations, resulting in 
unambiguous relationships regarding responsioility and management of 
the use of inforeztics 


- Fit the operational structure cof user populations, resulting in 4n 
easier flow of informatior 


- Effect the match between the ulers needs and *he resources to fulfil 
them in an economical manner 


2.2 Distribution ef Hosts 


"he basic organisational entity is the Local User Community. It must fave a 
close working relationship and be charactertced by intensive interworking and a 
comeon requirement for specific sets of services. This should justify the cost 
of providing local si pport and managerent 


From both an orgerisetionsal sd operational point of wvwiew, there is «a 
requirement that this local support and sianagement shovld cover 


The administration ef equipment lincluding hardware, software, data 
and local communications) ; 


The control of access to these resources from both the economical and 
security points of view, including identification, authentication and 
addressing of users 





A local user community will generally coincide with an organisational unit such 
as a department within a single site. “Site” is not necessarily the same as 
“building”. There may be more than one site within a building, or there may 
exist links between buildings to enable treatment as an unit. 


The hardware, software and support which is dedicated to a local user community 
is called a Local Support Unit {LSU} and it is put under the operationsl 
supervision of a Local Systems Administrator (LSA). 


A LSU should serve as large a user community as possible. If, however, a user 
community is divided geographically in a manner that cannot be supported 
economically by a single LSU, it should be served by different LSUs. Similarly, 
if a large user community consists of groups carrying out activities with 
little or no interaction, it should be served by different LSUs. 


As an L'Y is thus an autonomous unit, whose physical separation enhances its 
security. 


An LSU is composed of local hosts. personal hosts and workstations with the 
necessary servers. A personal host is dedicated to a single user at a time and 
therefore is, in principle, built inte a self-contained workstation, such as a 
personal computer (PC). 


The resources within an LSU are interconnected through a Local Communications 
Network (LCN). As the LSU itself, an LCN is a conceptual/organisational link 
between resources and does not imply a specific technology. It can be 
implemented through various technologies such as asynchronous communications, a 
packet switching network, or a Local Area Network (LAN). The term LAN whenever 
encountered in this document does not refer to the LCN, but to a specific 
technology through which it is implemented. 


Hosts which, for whatever reason, are not part of an LSU, but deliver services 
to families of LS!'s, to the entire private domain in which they operate, or to 
other private domains, are called common hosts. They constitute Common Support 
Units (CSU) under the operational supervision of Common Systems Administrators 
(CSA). 


The geographical location of CSUs is generally remote from the LSUs. They are 
concentrated in Computer Centres or in Telecommunication Centres. 


LSUs and CSUs are interconnected by 2 Domain Communication Network (DCN) while 
interdomain communication uses the Public Communication Networks (PCN). 


The relationship between the support units of a domain, and the inter-domain 
relationships ars shown in the next diagram : 
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The two level architecture of LSts and CSUs is intended for large and 
geographically spread organisations. Small Organisations located in one 
building are suggested to follow an architecture similar to a that of single 
LSU. A gateway to the public netwoiks could then contain a mini 
telecommunication centre. 


Other deviations from ‘he general model may occur when members of a local user 
community are not in the same office area but at a larger distance. If this is 
an exception, a pragmatic ad-hoc solution must be found without changing the 
architecture guidelines. There are cases, however, where user communities are 
spread ove: different countries le.g. international committees), or even 
composed of mobile members (e.g members of the European Parliament). 


Two solutions are then recommended 


If there can exist, somewhere, administrative and/or secretarial support 
for the community, this can be organised as an LSU providing a service 
access point. The distant workstations, preferably personal computers, are 
then connected by the inter- and intra-domain communication networks to the 
LSU from where all the services for the loral community can be accessed ; 


- If such a service entry point cannot be provided, each member is then 
equipped with a “single workstation LSU", again based on a personal 
computer, but even, in some cases, simply with a terminal linked to the 
Videotex services provided by the national PT'%s ; the latter provides 
almost a “unidirectional” LSS. In this solution, isolated autonomous users 
are consicered as single member communities. 


ll 








2.3 Distribution of Servers 


Servers can be classified in different categories 
# personal server can be allocated to a single user 


a local server cannot be allocated to a single user because its services 
are. by definition, to be shared by the members of a local user community 
‘e.g. departmental data) 


7 @ common server cannot be allocated to a local user community because its 
S@rvices are, by definition, to be shared by several local user 
Communities, the whole domain, and possibly user communities outside the 
domain. 


an external server. by definition, has to be accessed through inter-domain 
Communication 


In general, the distribution of servers follows the pattern of distribution of 
data 


It seems logical to locate personal, local and common servers on personal, 
local and common hosts respectively. For diminishing technical and economical 
reasons, servers are often installed further upstream from the user ; in the 
past. all servers were located on a common central computer. 


It is therefore possible that text aod graphical processing are still provided 
Dy local and even common hosts, and that local applications, including local 
Gata bases, are run on common hosts. This would be the exception rather than 
the rule. Heavy batch processing and number crunching will continue on large 
mainframes for economical reasons 


It is technically feasible to locate servers downstream from their normal 
position and place common servers on local hosts. This would be undesirable, 
for purely organisational reasons : to migrate from a centralised way of using 
informatics to one in which any user community can provide services to any 
other is associated with problems of security, responsibility and resource 
management. Such an approach is, therefore, in contradiction with the 
Org4enisational principles of the architecture, stating that only CSUs have the 
MiSSion of a domain wide coverage of services. 


Although it should be technically possible for any server to communicate with 
any other server (see dotted lines on next diagram), the architecture must also 
foresee features allowing or cbliging the user to call upon a local server 
before accessing @ common server, or a common server before accessing an 
external one. This will assure compatibility bridging, added value operations, 
security and better administration and control. Local and common hosts and 
servers must, therefore, provide adequate pass-through facil/ties. 
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In summary, servers are the resources in operational form. They have to respond 
directly to user requirements ; their operation must follow the organisational 


structure of the users. 


The mapping of personal, local and central servers om personal, local and 
central hosts should follow the dictates of economics If it were _ 
necessary to map a personal server ona central host, this would be or 
economical. and not technical or organisational considerations 


Such mapping as there may be should, as much as possible, be transparent and 
esaventent to the end user. Hence, an emphasis on “pass-through” facilities 
enable different hosts, aod through them servers, to be accessed from a single 


workstation. 


2.4 Constraints 


The planned architecture Cannot be achieved overnight because 


J Many of the standards necessary for fully open systems do not exist yet, 
especially in the higher levels of the OSI model 


® The state of the art of integration is not mature enough for the 
implementation of the architecture. Industry progresses slowly and in 
different directions in the development of s¥pndard products. The PTTs have 
not progressed enough in the consistent implementation of their own 
standards at the European level. 


* The shift from central to local processing and from domain to local 
communications should mot take place ata faster rate than can be 
economically justified An economical balance must be struck between the 
rate of decrease in local hardware costs, the cost of new software. and the 
need to avoid chromic congestion of the CSUs and the OCH. 
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. The economical life cycle of existing equipment must be taken into account 
for its economical replacement 


. The training needed to implement the plan is considerable It can only be 


carried owt over some time ; especially as not all users have the same 
degree of motivation 


A gradual attainment of the goal it necessary. The speed of evolution will 
depend on the factors mentioned above. as well as on technological development 


2.5 Evolution 


In the past, central hosts from different manufacturers generated separate 
networks of terminals and remote ob entry points through proprietory 


communication methods There was little interconnection between equipment from 
different “empires”. This is shown in the diagram below 
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The diagrae that follows shows the principles of implementation of the 
organisation shown in section 2.2 
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This Giegram shows an aim to carry out communication between domains primarily 
through the Integrated Service Dats Network (150m). at the local level, the 
equipment of an LSU is connected through the local communication network, 
implemented a6 4 Local Area Network [LAN) 


The transition from the past architecture (fig 05) to the future one (fig. 06) 
must be carried ovt in steps forming an evolution which tekes into account the 
constraints explained in section 2.4. The imolementation of theses steps is the 
following (with the CEC plan shown in brackets) 


Replacement of proprietory terminals by multi-protocol terminals (84-66) 


— Expension of local computers supporting standard terminal and personel 
computer connections with pass-through to CSU's (83-90! 


Introduction of multi-vendor operating systems for LSUS (UNTX and MS-DOS) 
(4-90) 
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Introduction of packet switching data network for OCH and LCN communication 
(85). and phasing out of Dinary synchronous comsunication (85-87) 


Installation of multi-wendor file and job transfer (1963-19867) 


Installation of software products le.g pens) covering as many 
CSU-mainframes as possible (64-87) 


Selection of office and professional software products for selected 
opereting systems creating @ common end-user environment (85-67) 


Phasing out of stand-alone text processors tc be replaced by personal 
computers supporting equivalent text processing functions (86-90) 


Implementation of electronic mail services (86-90) 
Construction of Telecommunication Centre (67-98) 


Introduction of standard LAN-technmology for LCONs in order to off-load the 
PSON 2:0 assure integration and resource sharing of LSU equipment (67-90) 


High speed interconnection: of computer centre mainframes (88) 


Introduction of User Agent Services (see 5.1) and Information Dissemination 
Services (see 5.3) (87-89) 


Replacement of DCN telephone and packet switching data network by ISON 
{1991 and beyond) 








3 STANDARDS 


3.1 Interworking 


The ability of users in different domains to interwork is en importent sia of 
the architecture. Standards sre essential for integration of data. test, 
graphics. image. voice. etc. in «en interworking environment. end condition the 
Gecisions on the structure of the proposed erchitecture. 


There exist the following problems 


° Complete and option free sets of interrelated standards sust be sveilebdle 
to implement end-to-end interworking 


The development of international standards hes not reached this state of 
completeness. espec‘slly in the upper lay ors of the OSI model. 


The Functional Standard Profiles brought forward by CEN/CEWELEC/CEPT and 
the industry are the appropriate solution to this probles. "hey will be 
adhered to completely. as well as the European standards resulting from 
them (EN) 


® In order to turn @ paper standard into « de-facto stenderd, it it necessary 
thet it should be implemented on the market place #6 dictated Dy market 
forces 


° When a product claims coeplience with «a standard. there must exist & means 
of testing this clsim. Tie crestion of Conformance Testing Centres (CTCs! 
is on important element in this and will be weed for testing such 
compliance 


The following elements of standardisation pley en importent role in the 
implementation of the propesed architecture 


. Open Systems Interconnection (051) 
- Tran portability of Software 

- Human Interworking 

- Security and Resource Management 


1? 











3.2 Open Systems Interconnectio= - (051) 


The OSI principle will be spplied throughout. This is s recommendation from the 
International Standards Organisation (150). laying owt the guidelines for a 
layered model of communication It must be interpreted compatidly in the 
creation of different standards. 


The layers on which internstionsal agreement has been ceaeched. sallow 
equipment to intercommunicate But not to interwork. The following rules are 
laid owt in the context of an intercept strategy 


* The implementation of internetional standards becomes mandatory 45 soon 45 
commercially available products make it feasible 


® Protocols corresponding to OSI lewels. for which en internstionsl standard 
is mot ratified, will be implemented with intercept stendaerds. There is an 
urgent need for a full set of intercepts to be completed. especially ‘for 
the upper leyers 


3} } Tramspertebility of Servers end Operseting Systems 


To benefit from independence from individwel manufecturers. it showld be 
possible to place the seme servers on different hosts. Thus 


. Conversion anc disturbance costs sere reduced when changing computers. 
especially as their product life-span hes Become much shorter than thet of 
software 


° Applicetion servers can be sheared 

° Training and staff costs are reduced 

Trantportable, maenufecturer-independent. operseting systems heave been maturing 
in recent years These provide the conditions for the develogeent of commonly 
supported software. By enlarging the size of the merket for any one product 
Commonly available operating systems should be de-facto standards #8 long a8 0 
spp lication interfece standerds exist 

} 4 Humen Interworking 

Interworking. a6 wnderstood by the user. involves @ BSrosder environment then 
OST ant portebility. Integration throwgh ‘user standards is needed in areas 
such as 

° Common commend and access procedures 

° Common terminology 


. Common definition of office procedures 


The isswes @rising out of these requirements ere discussed further in chapter * 
of this report 
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3.5 Security and Resource Management 


More users can access a single host or server through 8 network than ever 
before ; the identity of these users is mot always easy to establish. 


Economical use of resources. priority settlement. and control of usege to avoid 
congestion. owerload. and degradation of quality of service have become major 
issves of concern 


These sre not communication problems. but ones of security and mansgement of 
resources. There sre wery few standards in these areas and their promulgstion 
is urgent. They showid cower identification and suthentication procedures for 
people and equipment. ercryption, access control, accounting. and 
implementation of rules of interne] control 
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4. IMPLEMENTATION OF THE ARCHITECTURE 


4.1 Implementation Strategy 


To implement (Che architecture in « gredusl end coherent manner. « strategy. 
ensuring thet staenderds sre not only crested bwt sliso encowrsged in their 
umplementation and adhered to in the use of informatics. is needed. This hes 
the following elements 


. The precess of standards aaking and intercepting ouwght to be 
accelerated Thi. is recognised by the CEC. the Member ‘Stetes and 
industry alike and the effort put in the SOGT-CcEPT and 
SOGITS-CEN/CEWELEC should be followed closely 


The priorities must be defined in line with the customer 
implementation problems. which sare in the first instence the phasing 
out of proprietory eretecols for remote interactive communicetion, 
file transfer end me,iege hendling. as well as the creation of stable 
application interfaces 


® The cooperation of venders of differert informatics products sand 
services with each other ss well es with the CEC ought to continue and 
be extended in new sress to ensure that standard solutions to problems 
are furnished, and thet any sedaeptaetions in existing products are made 
#veiladle to the whole market 


The present guidelines provide valuable information for industry on 
the criticel problems s customer meets when implementing a 
multi-wendor standards policy. 


⸗ The cooperstion of the PTTs must be ensured in permitting identical 
implementations of standerds in different public domsins Without 
this. inter-domsin interworking will be “empered by inefficiency and 
high costs of communicetion. even in the most standardised 
intre-domein solutions. 


° Cooperstion between the Eurepesn Institutions and the Administrations 
of the Meaber ttetes showld continue with common projects such as 
INSIS and CADOIA, and even enhanced. to schiewe the lewel of agreement 
end standardisation necetsary for inter-domsein communication. This is 
importent. given thet integration will not take plece on «8 separate 
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network alongside the mational ones. but at the lewel of the national 
networks. It will comwert the intercommunication te be achiewed in 
cooperation with the PTTs to interworking between domains 


The European Institutions and the Administrations of the Member States 
can state their requirements through their role as “clients” of 
informetion technology. The establishment of a precurement policy 
based on commen procurement specifications has a very positive role to 
play. and the role of the Standards Implementation Committee (SIC) in 
promoting the architecture is a key one, ensuring thet compatible 


options are selected and that testing compliance of products is 
feasible. 


⸗ The resources. hardware and software, which. for the components of the 
proposed architecture. are obteined throwgh calls fer tender. These will 
insist on adherence to common procurement specificetions. A simplified and 
well publicised tendering procedure will be sdopted. able to be carried ovt 
on an almost permanent basis. This will sallow 


Everly soread workloed in updating procurement specifications ; 
Possibility of mew products, improving the aerchitectwre, to be 
considered as soon as they are available on the market ; 

Peduction of tender preparation worklosed for the suppliers 

Simplified screening of products and evenly spresd workload in testing 
them 

High visibility of procurement policy and implementation of 
standard«. both for the suppliers and the Administrations of the 
Memher State« 

Advance information on requirements which become mandstory for future 
calls for tender 


, The end esers of informatics aust be aware of the strategy asdopted ‘o 
encourage the adoptios of this strategy in wser communities. guidelines for 
the use of hardware and software have been orepered These define the 

ategories of prodxcts in terms of the support thet will Be provided to 
them and give preference to those prodvcts thet enhance the strategy 
while making allowance for special cases and for «8 smooth transition 
period 


° Equipment which does not comply with the architecture will be phased out «+ 
its useful Life ends, to be replaced with standard equipment. Only this way 
will cycles of dependency be svoided. which may otherwise perpetuate the 
presence of non standard solutions 


4.2 Inter-Domsin Communication 


The responsible organisation of each domain has to marege 8 planned evolution 
towards the intra-domein architecture of its choice end design The cc 
implementation is described in sections 4 3 to 4&.$, end in section S$ for 
different services 
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To realise inter-domsin interworking. s compstible evolution of thn 
intra-Gomain architectures is necessary. To achiewe this compatibility. there 
is # need mot only for standarcs to be defined. bwt also for wsers. the 
harOware anc software industries, and the PITs to comply with thee In 
particular, the PI's must make the services based on these standerds available. 
notably 


Leased lines 

° Data networks 

: Telex and Teletex 
Public Electronic Mail 
Videotex Services 
Teleconferencing 


It 8 proposed to wse the most advanced public serwices for inter-domein 
communication on condition that harmonised implementation throughout Europe is 
avalledle within the required time-frame. Where this is mot the case, the same 
service will hawe to be orgeniszd By direct inter-domsin cooperation of 
telecommunications centres using public data networks or leased lines. For such 
cases. the CEC proposes to its partners the same standards implementation for 
inter-domsin communication as)6 6it)6«6hes) = 6atopted for antra-domain t.Su/CSU 
communication (see section 4.3 and section $) 


In the organisation of inter-domsin communication, telecommunicetion centres 
‘see § 4.3) play an essential role Consequently, telecommunicatio« domsin 
managers shovld meet to agret on common convertions and to prepsere & common 
customer position with respect te public services 


4 }) Intra-Domsin Communication 


In this section, the three entities thet provide the interconnection of 
equipment within « domein are censidered 


e The Domain Communication Network (008) which links the LSUs and the CSUs, 

° The Locel Communication Metwork (LCN) which Links the equipment of an LSU. 

° The Telecommunications Centres ehich owersee communications on the DCH and 
provide « gateway between the OCH and the public setworks, ofr the networks 
of other domains 


In a@dition to interconmection, the principles of information exchange sre 
considered in this section consisting of 


° Pemote Interact’ ve Commerication and 
° File and Job Transfer 


User services will be discussed in section $$. A more deteiled discussion of the 
standards profiles sedopted is given in th? snnex 


To provide the connections secessery. Both the OCH end the LC will use 
Gifferent. But coexisting, communication technologies for some time 
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e Domain Communication Network (DCN! must ewentwelly achiewe integration with 
tre ISON (Integrated Serwices Data Network). Before this integration, it will 
sce a PSON (Packet Switched Data Nctwork!). the priwate CSTN [Circuit Switched 
eleptone Network). leased iines and, possibly. LAN technology for single large 


Suildings 


within the Local Communication Network {LCN}. the evolutionary introduction of 
roemisting technologies will ensure workstation and interhost communication 
Thais will start with direct connections of terminals to local hosts. continve 

th interhost conmmections By the PSON and finally end up with LAN technology 
and pre-ISONW digital exchanges 


Fucept for urgent cases the general introduction of LAN-technology will te 
Phased on a competitive range of products supporting international standards 
The first implementation of LAN will be using Ethernet technclogy because this 
i* the most widely spread to date. and well supported Sy CEN/CENELEC functional 
standards profiles. This does mot include cheap LAN products with V24 interface 
for workstation to local host communications 


Remote interactive communication lags far behind other fields in 
starctardisation. The long awaited [50 Virtual Terminal Protocols are far from 
approaching definition. and seem to pursue a moving target At the same time 


an important class of commercially available teresinals ts sufficiently close to 
conformance with a subset of existing IS0 standards. It is thus irportant that 
the standards committees decide on an intermediate standard subset which is 
loc to general current practice otherwise software suppliers will continve 
*o fevelop products interfacing with proprietary protocols ant hardware 

peliers will keep their customers captive to their product range. This is yet 
smother example from a class of interconnected standardisation issues for whict 
if ne solution is found soon the overall purpose of the standardisation 
process is put at risk 


A proposal of a ‘feasible approach is explained in the annex. Until a solution 
is fond, ad-hoc and awkward solutions in the form of multiprotocol converters 
are forced wpon the architecture (see section 4.4) which must only be 
temporary 


Tile and Job Yransfer between different computers in the Commission has become 
an urgent wser need As 2 result, the Multilateral File Transfer System (FITS) 
nas been developed with references to WIFTP and ECMA standards on *.25 
networks 


MFTS is available on 852090 Siemens). VME {ICL} and 4S-00S computers. MFTS 
will be available on UNIX-V¥ in early 987. on MVS (Ccompat.[8™) in mid-1987 and 
on GCOS-8 (BULL) in 1988 


MFTS will be replaced by IS0-F. AM (File Transfer, Access & Management) and by 
159-JT™ (Jobw Transfer & Manipulation!) as soon as these standards are available 
i* products 





The functionality of MFTS, FTAM, and JIM is as follows 





| MFIS | FIAM | JIM | 
| | | | 
* file Transfer & Management } x | xX | | 
| | | | 
* Hierarchically structured files | | x | | 
| | | | 
* File Access | |} x | | 
| | | | 
* Binary Files | x ¥ | | 
| | | | 
t Remote Job execution | xX | Xx | 
| | | | 
t Remote printing |} xX | | x | 
| | | | 


Telecommunication Centres {TC} have, as their primary role, to provide central 
services and, possibly, control over communications oriented operations. The 
precise definition of the functions of the TCs after the introduction of ISON 
is beyond the time horizon of this document. They may include such functions 
as: 


- Communication servers for the Domain Communication Network, such as for 
electronic mail (see section 5.4) 


- Gateways between the DCN and the public communication networks (PCN) 


- An integration between different communication carriers until such time as 
a proper integrated service can be implemented (ISON) 


- Network management servers 
- Ante servers (see section 5.1). 
Telecommunications centers will use computers with fast processing capacity for 


filtering, fast temporary storage (buffering) and less emphasis on long term 
mass storage capacity. 
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4.4 Local Support Units 


Conformant to the policy of prefering products which enhance the 
tranmsportability of servers, is a decision to limit precsrietory operating 
systems , and not to introduce new ones unless they are cenerally availatle on 
equipment of several manufacturers. Of such operatiug systems, MS-DOS and UNIX 
have been selected ; the former for single uwrtis *usts (workstations), and the 
latter for single - and multi- user hosts. 


In the case of UNIX, portability is further enhanced by the formation of the 
X/OPEN group of manufacturers specifying a standard definition of the interface 
to the UNIX operating system . As this standardised interface is primarily to 
ensure the portability of applications, preference is given to softwares whose 
interface with the host environment conforms to that defined by the X/OPEN 
specifications. Cooperation will allow the definitions to be extended to new 
pertinent areas such as the support of extended multi-lingual character sets. 


This is expected to have a profound effect on the configuration of LSU 
resources, 7s they will for their greatest part consist of new installations. 
However, this policy does not preclude the installation on non-UNIX systems on 
LSUs. Non-UNIX systems will continue to be installed as long a continuity needs 
to be preserved with existing servers based on proprietory operating systems. 


Selection of software has a much more important impact on hardware selection 
than it has ever had in the past. Software packages can contribute to a drastic 
decrease in the cost of developing complete applications and acceleration of 
their use is economically expedient. Such packages should be available on as 
many systems as possible. 


A coherent set of software products that should be selected for the LSUs should 
provide servers for the following functions 


- Ante-Server (see section 5.1) - Mail Server 

- Text processing - Business Graphics 

- Data Entry - Advanced Graphics 

- File Server ~- Cartography 

- Structured Data Bases - Document Composition 
- Document Otat Bases - Statistics 

— VIX Data Bases - Spreadsheet 

- Thesaurus - Desktop 

- Data Dictionary — Compilers/Interpreters 
- Print Servers - Screen Formatting 

- Report Writer ~ etc... 
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To economise on the human resources required for training and user support. it 
is mecessary to limit unnecessary redundancy in the packages to fulfill these 
functions. Equipment that cannot support selected pickages,. therefore. stands a 
smaller chance of being acceptable, despite its intrinsic merits as a product. 


The tasks that need to be carried out within a local user community should be 
appropriately distributed between local and personal computers : the higher the 
requirement from a server interactivity and immediate response, the more it 
ought to reside on a personal host ; requirements of common access to data, on 
the other hand, will dictate the location of a server on a local host. 


For the user to feel at home independently of the host. or even the software 
being used, standardisation of the user interfaces is important, whenever 
possible, in different classes of application. Thus 


- SQL is adopted as the standard interface to relational databases 
CCL for documentary databases, enhanced by a system of menus ; 


It would be desirable to adopt such widely acceptable interfaces in the areas 
of graphics, an¢t end-user programming languages. APL is widely used as an 
end-user programming language, but it is not suitable for all purposes; at the 
same time, 4th Generation Languages are too new to have established themselves, 
let alone be moving towards standard interfaces. 


The ena user should also have available the means of printing close to the 
workstation, at least for draft quality printing. Higher quality printing will 
generally be available through printer servers residing on local hosts. 


Necessary conditions to reach the desired target are 
- the removal of proprietory terminals, permitting the principles of a single 
integrated workstation to be implemented in a standard way (see Annex) 


- the introduction of cost effective technology for the efficient 
implementation of the LCN. 
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* Fig. O87 : In the short term. «8 proprietory witi-proetecol converter 
(HPC) installed at the CSU and LSU lewels will permit the 
connection of stenderd terminals to the CSU hosts. to UNIX 
and non-UNIX hosts. For the connection of workstations to 
hosts within an LSU. cheep LANs Dased on V24 interfaces may 
also be used. 


* fig. O7 bis : As equipment is phased out the following changes take plece: 


- PAOs disappear with terminals accessing the OCH vie the UNIX 
computers 

- Word processing equipment is replaced by PCs 

- Access to non-UNIX computers in an (LSU is cerried owt 
entirely through PCs or standard terminals 

- PCs cease to be connected directly to the PSON. MFTS being 
available om UNIX 


* Fig. VO ter LANs are introduced resulting in 


- UNIX local computers without workstations 

- The connection of PCs on the LAN for sharing resources 

- The MPC becomes a server with @ standard interface towards 
the LAN and «a proprietory interface towards the son UNIT 
local computer 
A gateway between the LCN and the DCW is introduced 


* Fig. O7 quatro : The target is reached. and the MPCs removed. once =a 
functional standard ewists and is implemented for the 
connection of standard twrminals to the non-UNIX local 
computers 


The importance of pass-through facilities cannot be over-emphasised 


4.5 Common Support Units 

The components through which a Common Support Unit provides its services sre 
mostly large computer hosts with fast processors and substantial storage 
capacity for central databases, as)6 Cowell as §60approprisate channels of 
communication. 


There are two main types of CSU : 


~ Computer Centres 
- Telecommunication Centres (see 4.3) 
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Meany Deterogeneous systems ere likely to be present for the foreseesble future 
of mainframe instelletions ecross. es well es within domeins. The disedventege 
of heterogeneity is reduced (whether the weer is in the seme domain or not) by: 


- Adoption of ‘“stenderd” sepplicetion softwere on e868 many instelletions ss 
possible providing the user with « consistent interfece ; 


Adoption of stendaerd intre-domsin communicetion on ell instelletions. es 
explained in settion 4.) end 4.4 fig OF 


. A high speed channel conmecting processors end ellowing the resources of 
ane computer to be seccessed wise snother one. 


In the CEC. the following ssinfreme operseting systems will be supported by the 
intra-domein communication explained in 4.) 


1c : vee 

\1*MENS : 8S 2600 

Ter » VRIC™S on AMDAHL 
Ter . MVS on AMDAHL 
rit : 6coOse 


The most importent general application softwere for which meximum coverage is 
persvued in the CEC includes ADAGAS/MATURAL-SAS ~ MIST@AL-BASIS. Videotex type 
servers will be added a6 soon as selection procedures sre completed. 

Standard user interfaces implemecting CCl (Common Command Language). S$0l and 
menu driven access will be generalized for all textual and numerical dats base 
sy tems 


For the future. the main mission of the Computer Centre will Be to set up end 
opersete the infrastructure for an tnformation Oisseminetion Serwice (10S - see 
section $.3). 














5 IMPLEMENTATION OF SERVICES 


5.1 User Agent Service (UAS) 


A user of the informatics architecture generally accesses servers and interacts 


with them. In so doing. the user is faced with a formidable array of interfaces 


as shown in the diagram below (User A) 







































































This complexity does not need to be that high because the choices of the user 
at any one time are generally limited to those of the object at hand ; for 
example, access toa database for information on a particular subject the 
user does not know on which host the information he is interested in resides, 
nor does he remember the procedures necessary to log into the appropriate one. 


To simplify the user interface, there will exist a User Agent Service (UAS) 
which will act as an “agent of the user” vis-a-vis the appropriate servers. 
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These servers may reside on different heterogeneous hosts which may belong to 
different domains 


The User Agent Service is implemented through ante-serwers (AS). An ante-server 
is 4 piece of software which interacts with the user. and acts on the user & 
behalf in interacting with the appropriste target servers 


The ante-server, therefore 
: Gives the user guidance in finding the location of the appropriate service; 


- Acts on the user s behalf to establish an appropriste connection and, 
possibly. provide translation services in formulating the user s query in 
terms that the entry server will understand 


Provides access control to services (identification/sauthentication) 
- Collects service accounting data of the resources used 


An ante-server behaves. with respect to a target serwice, as if it were the 
user. The other servers it interacts with are not awere of its existence. Thus. 
the ante-server an be the user of another ante-server. end of course have 
other ante-servers as users. We can, therefore distinguish a hierarchy of 
ante-servers as follows 


Common ante-servers 
Locs!l ante-servers 


Personal ante setverts 


This hierarchy is shown in the example diagram below 
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Im this Giagrem. the user snmteracts with an ante-servwer {AS} on the host on 
whic he/she is immediately connected Throwgh # cooperation of possibly many 
ASs. “entry serwers” (£Ss) are accessed on the asppropriste hosts. These may be 
the target servers or they may invoke other Girectly cooperating servers on the 


— Or different hosts prowiding. in the exemple abowe. three serwices (SE! te 
3) 


The personal ante-servwer is likely te exist if only te limit the choices 
Svelladle to the veer, for exemple by effecting « direct connection with « 
locel ente-server. 


Access control end seccounting will. of cowrse. be more developed for the common 
ante-servers. 


A central ente-server with dediceted host will be pert of the Telecommunicetion 
Centre and will senege the intre- end inter-domeir conmection calls to sll 
other aente-servers. 


To achiewe the desired tasks, an ante-serwer will hewe seccess to : 


Informetion on users tuser profiles) relating toe seccess control and 
technical competence. 
: Information on the terget servers and their environment 


These will be stored in databases describing services and users which will be 
aveiledle to the sdministrater of the User Agent Service. 


User Agent Services must be accessible by stenderd screen eode terminalis. 


5 2 Inferm@etion Preduction and Administration 
These are the services which : 


Help the user produce informstion for his/her own use. or for use by 
others Production can be originsl te.g. text processing). or it can 
consist of the modificetion of existing informetion te preduce ew 
information (decision support systems, the information necessary to update 
* Gate bese. etc.}. 


Help maenegement to sedmivister the information produced by registering the 
information produced (such es documents!) with unembiguvous identifiers. 
releting it to other items of information for easier future retrievel enc 
follow up of actions. 


For the production end edministretion of information, the date ere stored in « 
preduction dete bese. The resources teke the form of processing end storage 
capecity through servers on any type of hosts. 


Depending on whether the weer esintaining end accessing the information is the 
individusl wser, the lecel weet compunity or s group spreed over different 
locel user communities, the production dete bese will be personel. ilocel or 
Common 
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For personal anc locsel production dsts beses. the Locel Support Unit will 
Prowice the necessary resources (see sectior 4.4). Common rules for office 
procedures. decument sdéministretion. terminclogy ee¢ office document 


architecture (O04) aust assure communication of information between locel user 
Communities. 


Common production dats beses sre eaintsined in the Computer Centre (see section 
4.5). Am importent specisl case is the centrel erchiving of son-ective locel 
information thet hes te be asintained for the whole orgenisstion. 


5.3 Inferestion Disseminstion Service (185) 


Numerous daetebeses currently exist in the Ewropesen Institutions, contsining 
large smounts of inforastion. The potential weefulness of this information is 
mot fully exploited beceuse : 


- Access oreocedures are difficwit : 


- Petrievwsal lengueges sre difficewlt te wee end very from one syster to 
another . 


- dete beses are designed to fit lecel end limited wsege They ere production 
Gata Dases rether then dissemination date Dases ; 


- Information sbout existing information is insufficient 


To owercome this Derrier, oew Gate beses will be crested whose sie will be to 
Give easy access to the informstion seeded by & specific user grown. Such 
systems are called Gissemination Gata bases (308). They must sppeser to the end 
weer #6 @ single Gata base. ewer if different DBMS and different dete bases ere 
used to satisfy the needs of s user growp. The content of dissemination dats 
beses is Bbwilt woe of extrects from production or other Gisseminstion dates 
bases. Common 008 are. by Gefinition. leceted on CSU's (Computer Centre). 


An Information Dissemination Service (10%) is « service which presents « set of 
tools end an orgenisetionsl fremewort for the crestion, msintenence and 
interrogsetion of dissemination dete Bbeses. 195 offers 


- standard date base formats for specific types of information : for exemple. 
standard descriptions and/or presentation for bibliographic informetion - 
likewise for statistical, legal end terminclogicel information ; 


- stenderd fecilities te feed the 008. These include interfeces between 
production end dissemination databases, interfaces between 005 end other 
Gets sources. such os Telex/Teletex, text processing of photocomposition 
tepes. end direct date entry ; 


- ® wter-friendly interface for information seccess and menipuletion. 
explaining itself end aedaepteble te specific user needs. The interface is 
mot limited to « single dete base, But includes #11 Getebeses of interest 
to « weer group. It showld be harmonised with the VAS wser interface ; 
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. interfaces and tools to produce extracts of dats bases on magnetic tepes. 
read-only optical disk medis ({(CO-80N). micro-fiche or psper. or to 
Gown-losd dats onte ss iocel computer. end distribute documents Ddy 
electronic wail ; 


° facilities describing thi information that is swaileble. 


Defining and implementing standards is an essential element within [05 and is 
required at three lewels : 


Standards for the structuring of informstion. A homogeneous user interface 
anc sutometic Gets exchenge sre impossible withowt ttenderd rules for 
information structuring end formatting. Examples of existing standards sre 
CCF. UNISIST and FORNEX. 


Exchange standards sre to be based on more technical standards which do not 
Gescribe the content of the information. But only the technical formet. for 
exemplr. the representation of documents containing on unlimited number of 
wariadle lergth fields is defined in [50 2709. The implementation of such 
stenderds will decrease the effort of deweloping specific interfeces 
considerably 


- Stendaerds for «#8 wriaque presentetion of screens end menus Although 
Gifferent data menegement software might be weed for «s single O08. the 
system should sppesr to be based on «2 single homogereous softwere system. 
*tandard rules for dislogve and screen design must thus be spplied to ali 
sub-systems of [05 a6 well as to UAS and possibly to other services having 
a large user populstion 


$.4 Electronic Sail 


Electronic Mail showld sllow messages idocuments) of waeriows formats to be 
interchanged between users in the seme domain. a6 well a6 Ddetweern wuters in 
Gifferent domains. including ones owtside the Evropean Institutions 


Electronric Mail will be based on the Message Handling System standards, as 
Geveloped by the CCITT and 150 (MHS/MOTIS). 


Uetil such time as MHS products sre aweilable on the hosts selected for the 
present architecture, electronic meil will be besed on Teletex protocols 
supplemented with « message header, derived from and equivalent in scope to the 
CCITT K-430 recommendations 


This initial implementation of electronic mail will sllow urgent needs to be 
met while, at the seme time, it will ensure that the technical, human and 
eGministrative infrastructure is ready toe receive MHS products when they sre 
avaeilabdle. 


For economicel reasons, end in view of the trensient neture of the early 
implementation. it is not envisaged that each workstation showld be furnished 
with the Teletex interfaces necessary to implement electronic mail. Instead, 
these will be concentrated on local servers. 
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The development of electronic mail services is being carried owt in the 
framework of INSIS. and will de based on the relewant Evwropean Worms being 
Gefined by CEN-CEWELEC and CEPT. 


This development recognises the importence of the exchange of rewisebdle 
Gocuments within the context of electronic mail services. It. therefore. 
enriches the repertoire of standards on which these services are to be based Dy 
Proposing compliance with an Office Document Architecture. This is the ODA/ODIF 
standard from ISO (DP 8613). the kernel of which is sufficiently stable. 


The diagram below shows the distributed nature of electronic mail 
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The wser interacts with « wser agent (UA) to create or receive messages. The UA 
Liaises with « Directory Service Agent {0SA) to associate the names of other 
users of the electronic mail service with their addresses. This ends wp in the 
creation of an “envelope” which is submitted, with the message. to the Message 
Transfer Agent (MTA) Messages are relayed across MTAs until they reach the Ua 
of the recipient. An MTA wces the services of @ System Management Agent (SA) 
which provides management tools and referral services. 


There showld only be «a single MTA and a single SHA in each LSU. Directory 


Service Agents and ser Agents. on the other hend, are ideally distriduted to 
the workstations because they are directly related te the end user. Directory 
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*ervices will. howewer be prowi:ded at higher lewels also. through the 
electromic mail serwer of an LSU or the Telecommurications Centre for 
COmsin-wide or extra-dumain information 


A central O54 is maintained in the TC. whose MTA will act as a gatewsy to the 
electronic mail serwices of other domains. Conversion between the text formats 
‘Supported by the electronic mail serwice (150646. IS06937 end 150 OF/8612 wher 
fimalised) is carried owt at the Ta lewel Comwersion te one of these 


standards ‘ro say the internal format ofa word-processor as carried owt my 
the UA 


The serwices cowered are 


Communication with other private Gomsins wie the £275 pwblic serwices. wsin~s 
Common conmwertions defined By the CEN/CEMELEC functionsel stendaerd A/37tt .; 


Commernicetion with wsers of the HS services previded by the PITs. 
following the CEPT A/31* functionsl stenderd ; 


Communications within the domsin 


In implementing the electromic mail serwice, the following principles sre to be 
followed 


Stenderd protocols will be weed for the intercherge of text ower the OCH 
These will Be the PI/P? oretecels defined in the CCITT £.400 series of 
recommendations 


A standard eccess orvtoce] (FT!) will be weed te seccess the electrenic mail 
services Pending the eweilebility of this pretecol, commercially sveilabdle 
solutions will be weed ; 


To deal efficiently with the treffic thet will be generated, the sia shovid 
be to carry owt communication with the MTA within on LSU ower «8 LAN when 
this is feasidle. ead te dedicate « host toe an MTA when this is justified 


5.3 Application Services 
These services Giffer from the others in two ways 


the lewel at which they operste. They tend to deal with # specialist ares 
related te # topic of interest te one or wore sdministraetive section of the 
organisation 


⸗ their dependence on other services in carrying out some of their functions, 
ac well as the lect of dependence of other spplications on them : they ere 
the top of « hierarchy 


Although spplicetion services sre By fer the most importent category of 
services, a6 well in swumber,. in size of sate Bases and the tetel development 
cost. there is wery Little te ed@ for them from architectural point of vive. 
They hewe to foliow all the rules set owt in this document and rely #8 such as 
possible on the other services. 
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6. OSI - STANDARDS PROFILES 


6.1 Evolution 


A complete and coherent set of standards profiles. specifyirg options and 
intercepts. is necessary at all times for (he implementation of an 
architecture. ‘he table bDelow presents a synthesis of these profiles. Some 
important subjects are absent from this table. These are subjects for which 
neither an immediate standard solution is availsble nor is there enough 
information or experience for a decision on intercepts to be taken. These will 
be covered in the next edition of the Guidelines, and include the introduction 
of ISON. LANs for the Domain Communication Network ({0CN), and LANs other than 
Ethernet. 


The table shows that it is possible. today, to implement a coherent 
architecture with almost no proprietory protocols. The only important exception 
is interective communication. 


The evolution towards an ideal world of open systems has a vertical and 2 
horizontal component 


- Progress in the vertical sense takes place at the Transport Layer of the 
OS! model. Services which were previously built directly on the Network 
layer, now need to be lifted upwards to the Transport lsyer, becoming thus 
network independent (with the exception of x29) 


- Horizontal progress takes place as intercept profiles are replaced by OSI 
profiles as soon as they become available. This migration is shown by the 
arrows in the upper layers of the table below. 


The combination of both «a horizontal and a vertical evolution at the transport 
layer is the reason why this layer is shown twice: the evolution of the 
networks is towards a fully standardised OSI Transport Layer (4), while some 
services will temporarily *®ave to rely on the X-29 protocol or MPC which 
communicate directly with X-25 at the Network Layer (3). 
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| INTERACTIVE COMMUNICATION | FILE & JOB | MESSAGE 
| LINE HODE | SCREEN MODE J _IRANSFER | HANDLING _ 

| | | | | J™ + | ODA-KERNEL | 
| 7 | | | | FTAM + | INTERIM -> ‘ ! 
| APPLICATION | | | -->] CASE |SOLUTION MHS-MOTIS | 
| | | | = 
| | | | | | | 
| 6 | x.29 | MPC | | aSN-1 = | | 
| PRESENTATION | + | + ---> VSM | MFTS -->] CO-Pres | TELETEX -> MHS-MOTIS | 
| |} sic st |SICc $4 | | l ! 
| | | | 
1 5 | | | | | | 
| SESSION | | | -->]| BSS | TELETEX -> BAS | 
| ] | 4 L | 
| | | | | 
| 4 | | ISO CLASS & | | «0 ---> 180 CL | | 
| TRANSPORT | |+ Adaptation | |} cl oO 0.2.4 | TELETEX -> IS0 CL 0,4] 
| | | l 4 4 
Note : The services specified by the columns of the upper table should be 

able to acceszs the networks at the places where their layer 64 

(Transport) appears in the lower table. The two tables are 

horizontally independent. 
| | | | 
| 4 | | | ISO CLASS 0,2 | 1SO CLASS 4 | 
| TRANSPORT |} x.29 | mpc | | | 
| | l 4 | | 
| | | | 
| 3 | %.25 OR INTERNET | 
| NETWORK | CONNECTION ORIENTED | CONNECTIONLESS | 
| | l | 
| | | | 
| 2 | | | 
| DATA-LINK | HOLC (LAPB) | LLC | 
| l | 
| | | 
11 | | | 
| PHYSICAL | X.21 BIS | ETHERNET (CSMA/CO) | 
| | L | 

(oe ceeeeeeeeee PSON------------ 6 LAN- --------------- > 
<--DOMAIN COMMUNICATION-->|<--------- LOCAL COMMUNICATION-------------- > 
NETWORK NETWORK 


38 











6.2 Network 


The Domain Communication Network (DCN) showld be connection oriented at layer 3 
of the OSI-model to provide the necessary security, access management controls 
and) appropriate resource allocation. Moreover, s unique addressing scheme, 


identifying LSUs should be available on the OCN to ensure the necessary routing 
control. 


It is recognised that LAN implementation may imply connectionless (CL) local 
interhost communication at layer 3 (transport class 4) whereby the LSU is 
considered by the DCN as «a distributed end-system. LCNs, therefore, must be 
physically isolated from the DCN, and communicate through a gateway addressable 
by the DCN. This is also necessary for security reasons and in order to 
separate the responsibilities for access and resource control taken by the 
Local Systems Administrator, as distinct from the OCN management. Isolated 
pieces of LAN, of the same LCN (e.g. for geographically separated equipment and 
users of the same community) will be linked by LAN-bridges and not through the 
DCN. Of course, this does not restrict the exceptional cases of CLSUs 
corresponding to dispersed communities. such as international committees, or 


Single workstation LSUs to communicate directly through the OCN, and/or the 
public networks. 


The possible coexistence of direct end-to-end communication using different 
transport classes (class 0 and 2 at one end, with class 4 at the other) needs 
to be resolved at the LSU-gateway. For this reason, the structuring of layers 
at level 3 and/or 4 for all operational services has become of vital 
importance. This is a particular problem for three important basic services: 
interactive communication, fils and job transfer, and message handling. 


6.3 Interactive Communication 


Interactive line mode communication is implemented using the K-28 protocol and 
the SIC-S! specifications over the packet switched (X25) network. This type of 
communication will not evolve: instead it will be phased ovt and replaced by 
screen mode communication. 


However, the X29 protocol has to be supported on LANs to give access, in line 
mode, to either local or common hosts. PAD emulators on local and personal 
computers may be implemented on either : 


- connection oriented LAN over the [S50 network protocol (180 8208) without 
any transport protocol, or 


- connectionless LANs over the class 4 Transport protocol (180 8073) ; in 
this case, the X25/LAN gateway must provide the necessary adaptation to 
carry over the connection to hosts which use the X29 protocol over X25 
without any Transport protocol. 


Interactive screen mode communication between workstations and local or common 
servers, based on standard profiles, is very difficult to implement because 


- The long awaited Virtual Terminal Protocols (VTP) are still too far from 
being agreed to be considered for implementation ; 
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The widely available CCITT x-29 protocol does not conform with the OSI 
model. In addition, it relies on X-25 at layer 3 and not on transport 
protocols ; 


The existing ISO standards (e.g. IS0 6428) cover too wide a range of 
functions on one hand, while on the other they do not include advanced 
features such as graphics, nor they do not define all necessary function 
elements required by the OSI model. Commercially available terminals and 
software products offer different, and often incompatible, subsets of these 
standards. 


To support MPCs on LANs, a solution entirely parallel to the one suggested for 
X-23 above must be adopted. 


The planned scenario for screen mode communication has to resolve two issues : 


The interworking of the terminal and its access point, which may be located 
on a personal or local computer. It is proposed to adopt a standard which 
is a proper subset of already approved [S0-standards while, at the same 
time, close to the de-facto implementation of a sufficiently competitive 
range of commercially available terminals. Such a subset is defined in 
SIC-S4 and CEN/CENELEC will be asked to consider it urgently as an interim 
standard. 


The 1S80-subset proposed by SIC-S4 is based on a compromise, whereby 2s 
limited functionality {(VT200-like) is supported for remote communications 
(CSU-LSU and inter-domain), whereas higher functionality, such as graphics 
and image, is temporarily restricted to personal computers and 
communication with local computers. The SIC-S4 definition of the 1S0-subset 
includes: 


- 4x96 characters with upper/lower case, accented latin and greek 
{optional), current and special symbols, mosaic and colour 
(optional). 

- Cursor movements/tabulation/editing 

- Screen size 24x60 


SIC-S&4 also defines lower levels of funcionality, corresponding with 
VTt00-like terminals and line mode terminals, but which have to be 
supported by higher level terminals too. 


The interworking of the terminal access point and the remote host. 

To address this problem, it is proposed to define a functional profile, 
called Virtual Screen Mode (VSM), which again should be based on existing 
standards and be close to de-facto implementations of terminals, as defined 
in SIC-S&. This solution is technically similar to the one presently 
implemented with Multi Protocol Converters, with one fundamental difference 
: the screens transferred over the network will conform to # standard and 
will not be proprietary. This should provide an incentive in the market for 
the suppliers of application softwares and terminals to line up to this 
interim standard, instead of continuing to support proprietary protocols. 
It is most important that CEN/CENELEC should start working in this 
direction urgently. 
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6.4 File and Job Transfer 


Since the MFTS developments began in 1982, the Transport Station has been based 
on ECMA-72 class 0, which implied no Transport class negotiation. This 
Transport Station suited X-25 networks well. 


To allow MFTS to exchange files between a host connected to the X.25 network 
and a host connected to a LAN, some adaptation may be necessary depending on 
the OSI layer at which a Connection Oriented Service is provided : network or 
transport layer. 


- If the Connectionless Network Service (CL-NS) is used on the LAN, then the 
functional standard ENV.41.101 will apply. The MFTS end-system on the LAN 
will be based on the 1/621X profile, while the MFTS end-system on X.25 will 
be based on T/31! profile. Then, the X.25/LAN Relay Function will be based 
on the R2/31X! profile. 















































| MFTS | | MFTS | 
L | L l 
}1SO0 Transp. | [1S0 Transp. | 
[Class 4 | | 180 Transp. |! | 180 Transp.! [Class 0/2 | 
I | 1 Class 4 | | Class 0/2 J L | 
| INTERNET | | INTERNET | | x.25 | | x.25 | 
| l L I 4 4 L 4 
} utc | } tic | | HOLC | | HOLC ! 
= l L i 4 4 L 4 
| ETHERNET | | ETHERNET | |} v 2 ] |v 2 | 
L 4 i je l 4 4 
LAN CL-NS | x.25 CO-NS 
T/62'*x R/31xK!1 T/311 


To implement this solution, the Transport Station used by MFTS systems will 
need to be adopted : the LAN-MFTS systems will have to support « class 4 
Transport Station, and the X.25-MFTS systems will have to be adapted to a 
class 0/2 Transport Station supporting class negotiation. 


- If the Connection Oriented Network Service (CO-WS) om LANs is used, then 
the LAN-MFTS systems will be based on the T/61! profile whils X.25-MFTS 
systems based on T/31! profile ; the ¥X.25/LAN gateway will be based on the 
R/12 profile icf. CEN/CEWELEC profiles). 
































| wmFTS | | MFTS | 
LL l 1 4 
J 180 Transp.| | 180 Transp.! 
1 Class O/2_ 1 1 Class 0/2 1 
| x.25 | | x.25 J1 *X*.25 | {| x.25 | 
L | 4 4 L 4 
1 ! } we } woe ! | woLC | 
l 4 lL j 1 = 1 
| €TMeener | | ETHERNET 1 ve | |v 2 | 
l 4 4 4 = | 
| | | 
LAN CO-NS | x.25 CO-NS 
1/611 a/t2 T/311 
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In this solution, both LAN-MFTS systems and X-25 MFTS systems can remain 
unchanged fexcept for the network service interface on LAN) using the 
existing ECMA-72 class © Transport Station without class negotistion. fo 
conform fully with the T/31t profile. howewer, the Transport ‘Stations on 


both LAN and X.25 could be adapted to support transport class 0/2 and class 
negotiation. 


MFTS will be replaced by 150 based products #8 soon as these are able to 
replace the MFTS functionality. 


6.5 Message Yandling 


The message handling system will eventually conform to CCITT s 400 series of 
recommendations. [ts implementation is divided into two phases. the first being 
ready for operation end 1966. 


During the first phase. the application layer will consist of s mininue 
envelope sufficient for the immediate requirements, and similer in syntax to 
that defined in the CCITT *.430 recommendation During the second phese. it 
will migrate to standard envelopes and heseders as defined in the MHS /MOTIS 
model. in accordance with the functional profiles defined by CEN/CEWELEC/CEPT 
The document body will conform to the Office Socument Architecture and Profile, 
ast defined by 150. A stable kernel of ODA is proposed as am urgent interia 
standard for CEN/CENELEC approwal with the support of the INSIS community as 
well as the industry 


The presentation and session layers will ewolwe from Teletex based encodings 
ond protocols during the first phase to those required by the *.400 series of 
recommendations during the second phase. notably the connection oriented 
presentation and BAS session and conforming to the relewant profiles defined by 
CEN/CEWELEC/CEPT 


finally, the transport layer, which will again be based on the Teletex 170 
protocol during the first phase, will migrate to the [$0 [ransport of e class 
appropriate for the underlying network at any one time 
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6.6 References to Standards Used in the Tables 


S.' Interractive Communication 


* MPC “Multiple Protocol Converter” (besed on e private protocols) 

* SIC St : CEC SIC St “Teletype TTY Compatibility fequirements” 

* SIC S& : CEC SIC Sé& “Screen Mode Terminal Compatibility Sequirement™ 

* VS" “Virtwel Screen Mode” (waiting for CEMN/CEWELEC functional standard) 

* £2 “Packet Assembly/Disassembly Fecility (PAD) in « Public Bata Network” 

* E28 “OTE/OCE Interface for « Start-Stop Mode Data Terminal Equipment 
Accessing the Packet Assembly/Disessembly Facility (PAD) in @ Public 
Data Network sitwated in the seme Country” 

* £23 “Procedures for the Exchange of Control Information and User Data 
between « Packet Assembly/Oisassembly (PAD) Facility and «a Packet 
Mode OTE or another PAD 


6.2 File and Job Iransfer 


ASN-1 “Abstract Syntax Notetion One” / IS0/01S 8824.2 - IS0/01S 8825 
CASE “Common Application Service Element” / I[S0/01S 8649.2-ISO/O0IS 8650.2 
CO-Prs “Connection Oriented Presentation” / I1$0/0P 882212)-IS0/DF 8862212) 
ECMA-T2 Class 0 “Transport Protocol” Janwary 1961 
FIAM “File Trensfer, Access and Management” / 150/0P 8571 
J1# “Job Transfer and Manipulation” / [$0 86631 - IS0 8832 
METS “Multilateral File Transfer System” 
CEC File Transfer ~- Facilities based on NIFTP 
* Session 85S “150 Basic Synchronized Subset“ 


6.) Message handling 


* Interi# Solution : Message Header derived from CCITT «430 
* MHS-MOTIS “Message Handling System - Message Oriented Text Interchange 
System” (CCITT K400 Serie) 
CEN/CEWELEC profile a/32tt - ISO0/0IS #8505 
* ODA-Kernel “Office Docuecvnt Architecture” /1S0/01S 8619 
POA-3 “Occument Architecture Level” 
* Session BAS “ISO Basic Activity Subset~ 
* TELETEX includes : TE! (Presentation). 162 (Session) and TTC (Transport) 


6.4 Network and Communications 


* ETHERWET (CSMA-CD) Carrier Sense : sultiple access - collision detection 
ISO/OIS 8802.3 “Lecel Ares Network” 
MOLC (LAPS) High Lewel Dete-Link Control / 180 7776 
$0 Trensport class 0.7.4 : t$0/1S #8072 - ISO/TS 8079 
Cless © : simple class 
Class 2? : multiplexing class 
Class 4 : error detection and recovery class 
* LLC “Logical Link Control” / IS0/01S 8802.2 “Locel Ares Network” 
* £21 Dis : Use on POW of OTE which is designed for interfacing to 
synchronous CCITT V-serie modems, Version 1964 


CSO: 5500/A0464 END 
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